Domain Name Systems (DNS) are vulnerable by default to various types of attacks.
One of the biggest risks is DNS cache poisoning, which occurs when a DNS accepts spoofed DNS data, caches the malicious records, and potentially
sends them later in response to legitimate DNS request lookups. This attack typically relies on the attacker’s MITM ability on the network and can be used to redirect users from an intended
website to a malicious website.
To prevent these vulnerabilities, Domain Name System Security Extensions (DNSSEC) ensure the integrity and authenticity of DNS data by digitally
signing DNS zones.
The public key of a DNS zone used to validate signatures can be trusted as DNSSEC is based on the following chain of trust:
- The parent DNS zone adds a "fingerprint" of the public key of the child zone in a "DS record".
- The parent DNS zone signs it with its own private key.
- And this process continues until the root zone.
Ask Yourself Whether
The parent DNS zone (likely managed by the DNS registrar of the domain name) supports DNSSEC and
- The DNS zone is public (contains data such as public reachable IP addresses).
There is a risk if you answered yes to this question.
Recommended Secure Coding Practices
It’s recommended to use DNSSEC when creating private and public DNS zones.
Private DNS zones cannot be queried on the Internet and provide DNS name resolution for private networks. The risk of MITM attacks might be
considered low on these networks and therefore implementing DNSSEC is still recommended but not with a high priority.
Note: Choose a robust signing algorithm when setting up DNSSEC, such as rsasha256. The insecure rsasha1 algorithm should no longer be used.
Sensitive Code Example
resource "google_dns_managed_zone" "example" { # Sensitive: dnssec_config is missing
name = "foobar"
dns_name = "foo.bar."
}
Compliant Solution
resource "google_dns_managed_zone" "example" {
name = "foobar"
dns_name = "foo.bar."
dnssec_config {
default_key_specs {
algorithm = "rsasha256"
}
}
}
See
